1. Field of the Invention
The present invention relates to redundancy in Internet Protocol (IP) networks.
2. Description of the Related Art
In only a few years, Internet Protocol (IP) networks have proliferated and are now the most common type of network used in the telecommunications world. The simplicity and the efficiency of IP mainly contributed to this tremendous success. The IP world now faces the challenge of providing networking solutions for an ever-increasing number of needs, even though IP was not originally designed to fit these requirements. An example is the need for high availability of IP servers. IP does not provide any such redundancy mechanism.
A few solutions were proposed by the industry for responding to these specific needs. Most solutions are based on modifying IP applications to take into account redundancy needs. For example, the Dynamic Name Server (DNS) protocol requires each application to know the addresses of a primary DNS server and of a secondary DNS server both containing a common set of DNS entries. In case of failure of the primary DNS server, the application has first to acknowledge the lost of the primary DNS server and then contact the secondary DNS server to fulfill its DNS request. While this type of solution does provide redundancy for legacy services, applying the same concept to the development of the increasing number of new IP services and applications would be an undue burden. In other words, application-transparent IP redundancy mechanisms are still to be developed.
IP networks are widely known and have been, for example, described in the following request for comments (RFCs) documents of the Internet Engineering Task Force (IETF): RFC 791, RFC 792, RFC 919, RFC 922, RFC 950 and RFC 1112. These RFCs are also published by the IETF as Standard 5 (STD0005), which is herein included by reference.
Reference is now made to FIG. 1 that depicts one partial prior art solution for providing an application-transparent IP redundancy mechanism in an IP subnet 110 topology. FIG. 1 shows the IP subnet 110 containing a Primary IP Server 120, a Secondary IP Server 130 and a Router 140. The Primary IP Server 120 has a primary IP address valid in the subnet 110 and the Secondary IP Server 130 has a secondary IP address valid in the subnet 110. The Primary IP Server 120 and the Secondary IP Server 130 are connected with the router 140 through corresponding connections 172 and 174. The router 140, in turn, connects with another external network 180 through a connection 176. The router 140 receives traffic addressed to the primary IP address and forwards it through the connection 172 toward the Primary IP Server 120. The Primary IP Server 120 and the Secondary IP Server 130 use connections 172 and 174 to exchange information and assess the availability status of each other.
When a fault prevents traffic to reach the Primary IP Server 120, the prior art redundancy mechanism is activated by having the Secondary IP Server 130 taking over the responsibilities of the Primary IP server 120. This is achieved by assigning the primary IP address of the Primary IP Server 120 to the Secondary IP Server 130. When possible, the secondary IP address of the secondary IP Server 130 is assigned to the Primary IP Server 120. The purpose of this address swap is to allow the Secondary IP Server 130 to receive the traffic originally addressed to the Primary IP Server 120. The router 140 then forwards traffic addressed to the primary IP address on the connection 174 toward the Secondary IP Server 130. A major drawback of this solution is that the Primary IP Server 120 and the Secondary IP Server 130 must be in the same IP subnet 110 for the address swap to be possible. This limits the capabilities of the prior art redundancy mechanism since the IP subnet 110 must be located in one single physical location. Moreover, the address swap always represents a risk for the stability of the IP subnet 110 since both nodes could advertise the same IP address. This could happen, for example, when a node comes back online after a failure. Such a situation could lead to large latencies in the IP subnet 110 and render both nodes unreachable until the situation gets fixed.
As it can be appreciated, the prior art solutions do not provide an efficient redundancy mechanism in Internet Protocol (IP) networks that can be transparent to any IP application. The present invention provides such a solution.